hostname|jmxPort|nativeTransportPort
The startup configuration settings read by the RHQ Server are stored in the rhq-server.properties file located in the /bin directory of the server distribution. This file includes settings not persistent in the database (i.e. these startup settings are specific for a single RHQ Server instance - they are not applied across all RHQ Servers in the cloud). If you modify any setting in this file, you must restart the RHQ Server in order for the changes to take effect.
Due to some limitations within the app server, there are two RHQ settings that will not take effect immediately upon restart if you change their values after the initial installation. These are settings for the web connector's keystore and truststore file locations (rhq.server.tomcat.security.keystore.file and rhq.server.tomcat.security.truststore.file). If you ever need to change those values after you've installed RHQ, you will need to change them in the app server's standalone/configuration/standalone-full.xml file in the <ssl> node of the https <connector>.
This rhq-server.properties file defines typical server settings such as the TCP ports that RHQ Server components listen to and the security settings for the server-agent communications subsystem. The values are customized by you during the installation process as per your requirements.
Below are these startup properties.
The rhq-server.properties file contains the database username and password. This password is not obfuscated in earlier RHQ versions. Even in later versions where the password is obfuscated, a competent hacker can decrypt it. Therefore, ensure this file is protected from unwanted access.
These properties defines the RHQ Server's database and how it can connect to it.
|
rhq.server.database.type-mapping |
Defines the vendor of your database that will be used as RHQ's backend persistence store. The only supported values are PostgreSQL or Oracle. |
|
rhq.server.database.connection-url |
The JDBC URL that the RHQ Server will use when connecting to the database. An example is jdbc:postgresql://localhost:5432/rhq or jdbc:oracle:oci:@localhost:1521:orcl. |
|
rhq.server.database.driver-class |
The fully qualified class name of the JDBC driver that the RHQ Server will use to communicate with the database. An example is org.postgresql.Driver or oracle.jdbc.driver.OracleDriver. |
|
rhq.server.database.user-name |
The name of the user that the RHQ Server will use when logging into the database. This user must be the owner of the RHQ tables. |
|
rhq.server.database.password |
The password of the database user that is used by the RHQ Server when logging into the database. This is obfuscated. Use rhq-installer.[sh,bat] --dbpassword to provide you with an obfuscated password to enter for this value. |
|
rhq.server.database.server-name |
The server name where the database is found. This must match the server in the connection URL. Currently only used when connecting to PostgreSQL. |
|
rhq.server.database.port |
The port on which the database is listening. This must match the port in the connection URL. Currently only used when connecting to PostgreSQL. |
|
rhq.server.database.db-name |
The name of the database. This must match the name found in the connection URL. Currently only used when connecting to PostgreSQL. |
|
hibernate.dialect |
The name of the Hibernate dialect that identifies the strategy used by Hibernate to connect to and access your database. For example, the Postgres dialect is org.hibernate.dialect.PostgresSQLDialect. The other option is Oracle's dialect which is org.hibernate.dialect.Oracle10gDialect. |
|
rhq.server.quartz.driverDelegateClass |
Quartz is the scheduling engine used by RHQ. This is a Quartz configuration setting that is specific to your database and provides the strategy for how Quartz connects to and accesses your database. If using Postgres, this value should be org.quartz.impl.jdbcjobstore.PostgreSQLDelegate. If using Oracle, this value should be org.quartz.impl.jdbcjobstore.oracle.OracleDelegate. |
|
rhq.server.high-availability.name |
This is the unique name the RHQ Server. It doesn't necessarily have to be an IP address or hostname but it can be. The only restriction is that all server names be unique in the RHQ server cloud. If left blank, the RHQ Server will be assigned a name based on the machine's hostname. NOTE: if you are upgrading an existing server, this must be the same name as the server being upgraded. |
|
rhq.server.email.smtp-host |
The hostname of the SMTP server that is used when the RHQ Server sends emails. |
|
rhq.server.email.smtp-port |
The port that the RHQ Server will send emails over when communicating with the SMTP server. |
|
rhq.server.email.from-address |
The "From:" header of all emails sent by the RHQ Server. |
These are settings that bind the RHQ Server to particular IP addresses and ports. You will normally only need to change these if you have firewall issues that require specific addresses and ports to be used.
|
jboss.bind.address |
The RHQ GUI Console (among other services) will bind to this IP address. This is the host in the RHQ Console URLs; e.g. the myhost in http://myhost:7080. |
|
rhq.server.socket.binding.port.http |
The RHQ GUI Console will listen to this port for unsecured HTTP requests coming in. This is the port number in the RHQ Console URLs; e.g. the 7080 in http://localhost:7080. The server will accept incoming agent messages over this port if the agent is told to send messages to the server over the unsecured servlet protocol. |
|
rhq.server.socket.binding.port.https |
The RHQ GUI Console will listen to this port for secured HTTPS requests coming in. This is the port number in the RHQ Console URLs; e.g. the 7443 in https://localhost:7443. The server will accept incoming agent messages over this port if the agent is told to send messages to the server over the secured sslservlet protocol. |
|
rhq.server.socket.binding.port.# |
The rest of these are ports used internally by the RHQ Server. |
|
jboss.management.native.port |
Used by the installer to communicate to this server when completing the installation of the RHQ Server. This is also the port the RHQ Server agent plugin uses when you are managing the RHQ Server via the RHQ Agent itself. |
|
jboss.management.http.port |
This can be used by the JBossAS agent plugin when you are managing the RHQ Server via the RHQ Agent itself. |
|
jboss.management.https.port |
This can be used by the JBossAS agent plugin when you are managing the RHQ Server via the RHQ Agent itself. |
|
rhq.autoinstall.enabled |
Set this to true when you are ready to run the installer that completes your RHQ Server installation. |
|
rhq.autoinstall.database |
The allowed values for this setting are auto, overwrite, or skip.
|
|
rhq.autoinstall.public-endpoint-address |
public IP/hostname that all agents will use to talk to this server. If not set, a value to use is determined at auto-install time. |
|
rhq.cassandra.seeds |
This is set automatically when installing an RHQ Storage Node. It must be set manually only when installing an initial RHQ Server configured for remote RHQ Storage Nodes (i.e. rhqctl --server). It is ignored for additional HA RHQ Servers, which will find an RHQ Storage Node via entries in the RHQ Database. It is a comma-delimited list of seed nodes. There should be an entry for each installed RHQ Storage Node. The entries allows the initial RHQ Server to connect to the RHQ Storage Node cluster. Each entry consists of three fields that are pipe-delimited: hostname|jmxPort|nativeTransportPort The nativeTransportPort, which is the port for client access, must be the same for each node in this list. |
|
rhq.cassandra.username |
The username that will be used to authenticate against the storage node cluster |
|
rhq.cassandra.password |
The password that will be used to authenticate the username |
|
rhq.cassandra.client.compression-enabled |
If enabled data sent to and from storage nodes will be compressed using snappy compression. Note that this is an advanced configuration option. If you turn on client compression and your storage nodes do not support compression, then the RHQ server will not be able to connect to the storage cluster. The storage node will log the following at start up if it does not support compression,
Please make sure you do not find the above log statement in your storage logs before you enable client compression. |
|
rhq.server.log-level |
Sets the logging level for all RHQ code. If under normal operations, you should set this to INFO. However, when debugging problems with the RHQ Server, you can set this to DEBUG to enable more verbose logging. |
|
rhq.server.maintenance-mode-at-start |
If true, the server will start in maintenance mode at startup. If false, whatever mode the server was in when it shutdown will be the mode it will be in when it starts up. |
|
rhq.server.operation-timeout |
One of the features of RHQ is the ability to invoke operations on a resource. The RHQ Server will be able to ask an agent to invoke a particular operation on a particular resource managed by that agent. Because of the remote, asynchronous nature of operation invocations, alot of things can go wrong (the network goes down, the resource crashes, etc.). This operation timeout is the default number of seconds that the RHQ Server will wait for an operation to complete and an agent to provide the results. If this timeout expires, the operation will be considered to have failed. Note that this is only a fallback default value - individual operations can define their own timeouts (in the plugin descriptor) or individual operation invocations can themselves specify a timeout. Those override this default rhq.operation-timeout setting. |
|
rhq.server.plugin-scan-period-ms |
Periodically, the RHQ Server will scan it is local file system and the database to see if any changes have been made to deployed agent plugins and server plugins. This value is the amount of milliseconds the server waits before checking its plugins again. |
|
rhq.sync.endpoint-address |
When this is enabled (i.e. set to true), the server will, at start up, compare its endpoint address to the host name/address found on the host machine. If they differ, the server endpoint address will be updated to the value found on the host machine. This addresses the problem of address/host name changes that will occur in cloud deployments such as EC2 when a server machine is restarted. |
|
rhq.communications.connector.X |
These are communication configuration settings for the server's endpoint that agents will talk. See Communications Configuration and Securing Communications for details on these and related settings. |
|
rhq.communications.connector.security.X |
These are security settings for the server's endpoint that agents can talk securely to over the "sslsocket" protocol. See Securing Communications for details on these and related settings. |
|
rhq.server.tomcat.security.X |
These are security settings for the Tomcat web connector. These are used both during browser access and when agents talk to the server over the sslservlet protocol. See Securing Communications for details on these and related settings. |
|
rhq.server.client.security.X |
These are security settings the server used when sending messages to the agent. See Securing Communications for details on these and related settings. |
RHQ is designed to scale to large numbers of agents. The RHQ Server must, therefore, take into account the possibility that it could get flooded with messages if many or all agents attempt to communicate with the server simultaneously (as will be the case if the RHQ Server is restarted after being down for a while; RHQ Agents will detect the RHQ Server has come back up and will attempt to immediately send it a backlog of messages).
To help alleviate problems that could occur during high load, the RHQ Server is configured to limit the number of concurrent messages allowed to be processed by different subsystems within the RHQ Server. If more messages arrive concurrently, such that the limit is exceeded, those additional messages will be dropped and the agent will be asked to send them later. The following configuration settings define types of messages that have concurrency limits associated with them.
|
rhq.server.startup.web.max-connections |
RHQ limits the number of web connections that can be concurrently created. This includes GUI connections made by browsers. It may also include connections made by agents, if agent connections are made via the servlet or sslservlet transport. Note that if agent requests are routed over web connections, you should ensure that the Global Concurrency Limit is slightly lower than this Web Connections limit so as not to lock out GUI users from accessing the user interface during times of high agent load. This limit on web connections is the same for both non-secured http requests and secured https requests, so the total max connections allowed is actually twice what this setting is. For example, if the max web connections is set to 300, then 300 http requests will be allowed and 300 https requests will be allowed, for a possible total of 600 concurrent web connections. |
|
rhq.communications.global-concurrency-limit |
Aside from the Web Connections limit, all other concurrency limits will only affect incoming agent messages (not GUI/browser requests). This global concurrency limit will limit the total number of agent messages coming into the server, regardless of the type of message. In other words, if this global concurrency limit is set to 300, no more than 300 total agent messages can be processed at any one time, no matter what kinds of messages are coming in. The rest of the concurrency limit settings will put a limit on the number of messages of particular message types. Keep in mind that if other concurrency limits are set higher than this global limit, they are effectively capped at this global limit since you can never have more than this global limit number of messages concurrently being processed. |
|
rhq.server.concurrency-limit.inventory-report |
Inventory reports are sent from the agent when the agent starts up and periodically thereafter. Inventory reports can be large, depending on the number of resources on the agent machine. |
|
rhq.server.concurrency-limit.availability-report |
Availability reports are sent from the agent very often (typically every 5 minutes). Availability reports are usually very small, but occur in large numbers due to the high frequency of their transmission. |
|
rhq.server.concurrency-limit.inventory-sync |
Inventory synchronizations occur when the agent needs to synchronize its inventory with that of the server. Agents typically synchronize at startup. Traffic that flows as part of inventory synchronizations is usually large, depending upon the number of resources managed by the agent. |
|
rhq.server.concurrency-limit.content-report |
Content reports are similar to inventory reports except they contain information about discovered content (i.e. installed packages of software). These reports can be large depending on the number of installed software the agent has discovered and is managing. |
|
rhq.server.concurrency-limit.content-download |
Content downloads occur when a resource on an agent needs to ask for the content of a package version, usually for the purpose of installing the package. |
|
rhq.server.concurrency-limit.measurement-report |
Measurement reports are sent to the server periodically whenever the agent completes measurement collections. The number of measurement reports vary as do their size, depending on the number and frequency of measurements that are scheduled to be collected. The greater the number of schedule measurements the agent needs to collect, the more frequently measurement reports are sent and the larger they are. |
|
rhq.server.concurrency-limit.measurement-schedule-request |
Similar to inventory synchronization, measurement schedule requests are sent to the agent when the agent wants to ask the server for its up-to-date set of measurement schedules that have to be collected. |
|
rhq.server.concurrency-limit.configuration-update |
When the agent detects configuration changes, it will send those updated configurations unsolicited to the server. This limits the number of configuration updates a server can process. |